home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Aminet 2
/
Aminet AMIGA CDROM (1994)(Walnut Creek)[Feb 1994][W.O. 44790-1].iso
/
Aminet
/
gfx
/
show
/
AGMSFilm2.lha
/
AGMSFilm.doc
< prev
next >
Wrap
Text File
|
1993-01-05
|
6KB
|
110 lines
AGMS*Film --- The Story
AGMSMakeFilm, AGMSPlayFilm and AGMSBreakFilm are utilities for creating,
showing and destroying cartoons, including a stereo sound track.
What's the difference between these utilities and other programs (like
RTAP by Sebastiano Vigna and THUT's TASS) that play big ANIM5 cartoons
from hard disk? Sound and Speed!
I've been working on a ray traced cartoon (about 900 frames at 15 fps,
natural motion from my puppeteering software [Handyman] and rendering by
DKBTrace). After compiling the separate frames into an ANIM5 cartoon
with MakeAnim (a nice utility by an anonymous person - thanks!), RTAP
almost played my cartoon correctly. It had to pause once in a while to
suck data off the disk (even though it was reading a bit while playing
and had megabytes of buffers). Annoying. Even on an A3000 with a fast
hard drive (2.0 megabytes / sec measured performance including file
system overhead, 2.3 without file system). I wasn't able to test TASS's
performance.
Part of the problem is that the cartoon didn't compress at all well using
ANIM5. ANIM5 works by storing the full first frame and then only the pixels
that change from one frame to the next. It also does vertical run length
compression on top of that. Anyways, in the ANIM5 version of my cartoon
each compressed frame took up about 80% of the original image's size. Why?
Lots of changes from one frame to the next due to camera movement, complex
textures and lighting changes (moving sun behind moving clouds, rippling
water, etc).
Ok, so it doesn't compress too well. That just means it takes up more
space on the hard drive, right? Nope, the other problem is that it takes
a lot of CPU time to decompress and draw each frame. ANIM5 works so
well for ordinary cartoons because only a small part of the image
changes from frame to frame: only the moving bits are decompressed and
drawn. Usually the moving parts are your animated character while the
rest of the image is a static background. With my cartoon, everything
is moving. You might as well redraw the whole screen since it's all
changing anyways.
That's what AGMSPlayFilm does. It loads uncompressed audio and video
frames from the hard disk directly into the screen memory. No CPU time
wasted doing useless decompression. It also has the advantage of being
able to play the film backwards. The uncompressed format also means
that you could theoretically edit the film's contents in place -
replacing a single frame in the middle wouldn't mean having to redo all
the following frames like ANIM5 requires.
However, it does require a fast hard disk drive or a small picture. A
small price to pay for cartoons that let you do camera movement and
lighting changes! I put up with a 128x75 HAM image on my A2000 (15
frames per second, 20 kHz stereo sound, old GVP Series I non-DMA disk
controller [slow: 200K/s]). On my friend's A3000 we can do 352x232
overscanned HAM (15fps, 20kHz, 3000's fast DMA controller [2.0M/s]) with
CPU time and disk bandwidth to spare. People with A2000's and 2091
controllers can expect at least 500K/s, enough for 10 frames per second
320x200 HAM plus sound. Of course, if you have a slow disk drive then
even the best disk controller won't help. By the way, those disk speed
tests are off for big files - AmigaDOS has extra overhead for files that
are very long (but see that new 2.0 AddBuffers command...).
The file format is taken from the IFF standard. Unfortunately, it is a
part of the standard that few people use because of its complexity.
Basically, the film is a LIST containing the frames (cells) of the
animation. The LIST specifies shared properties for all the contained
objects (namely, the screen size and sound speed). Each frame within
the LIST is implemented as a CAT object (concatenation). The CAT holds
a FORM ILBM for the image part of the frame and a FORM 8SVX for the
sound track portion that goes with the image. So, programs like
AGMSPlaySound that can handle fancy IFF structures work but most others
will guru because they recognize it as IFF and then use buggy (probably
untested) LIST and CAT reading code. One final note, I'm using a
special type of LIST that requires that all the frames (CAT chunks) are
all exactly the same size and have the audio and video parts in the same
relative positions.
Well, it works. I can now put my cartoon on video tape without having
to buy / rent an expensive single frame recording device.
- Alex
References:
People have also mentioned something from THUT called TASS that was on
an AMIGA Plus Disk. While it isn't useful to me (I'm not endorsing it),
it can be useful for people dealing with ANIM5 cartoons, perhaps wanting
to convert them to IFF files for use with AGMSMakeFilm. TASS seems to
be a bunch of utilities useful for playing regular ANIM5 files from
disk, converting between ANIM5 and individual IFF pictures, and doing
other things. THUT also came out with a PD utility (before TASS?)
called ATI that just converted ANIM5 to IFF (a pain to use - have to
type in file name for each frame). Anyways, here's their address from
the TASS docs in case you want their stuff:
THUT Inc.
34 King St. E.
Suite #802
Toronto, Ontario, Canada
M5C 1E7
(705) 737-5998
BBS: (705) 737-5017
FAX: (416)-366-5966
Another way of converting ANIM5 cartoons to individual pictures is to use
Deluxe Paint IV from Electronic Arts. It has a new feature which lets you
save a series of pictures by specifying a count in the save a picture dialog
box.